1. 前言：每一天都在選模型卻從來沒有放在一起比過

Day 14 到 Day 16 看廣告圖用的是最便宜的 gemini-3.5-flash-lite，Day 18 寫素材草稿和 Day 19 比對廣告與頁面改用 gemini-3.6-flash，每一次選哪個模型都是照「簡單的事用便宜的、難一點的事用貴一點的」這個直覺決定的，這個直覺到底對不對，前面十幾天沒有整批驗證過，只有 Day 15 用六張圖順手試過一輪 3.6-flash，同一件事換一個模型會差多少、貴多少，手上沒有完整的數字。

模型的單價差距不小，以輸入來說 gemini-3.6-flash 是 gemini-3.5-flash-lite 的 2.5 倍，gemini-3.1-pro-preview 是 6 倍，素材只有 24 張的時候感覺不出來，換成每個月幾千張就是一筆要說明的支出，今天把前面做過的兩種題目原封不動拿出來，題目、答案和評分方式都不改，只換模型，量出三個等級各答對幾成、問 1,000 張要多少錢、一批要等多久。

今日核心目標：

1. 用同一份題目和同一份答案，讓三個等級的 Gemini 各做一次，把差別限制在模型本身
2. 分開看簡單題和難題，找出便宜的模型在哪一種題目夠用、在哪一種題目開始出錯
3. 把正確率、每 1,000 張的費用和一批的等待時間放在同一張表，當成之後選模型的依據

2. 系統架構全景與設計理念

💡 核心工程理念：

1. 只換模型，其他都不動：同一種題目的每個模型只有 endpoint 那一行不同，題目、欄位鎖法、輸出上限和思考設定都和原本那一天一樣，run.sh 在呼叫之前會把每一段 AI.GENERATE 去掉空白之後和 Day 16、Day 19 的原文逐字比對，有一個字不同就停下來
2. 答案是前幾天就寫好的：三張答案表在 Day 15、Day 16、Day 19 就 commit 了，今天完全沒有碰，每次評分記一次答案表的指紋，難題的指紋要和 Day 19 評分時相同，呼叫模型的 SQL 也不讀答案資料集
3. 問過的不再問：五個組合裡有兩個前幾天已經問過，直接沿用成功的紀錄，沿用的兩組重新評分後，四個分類欄位要和 Day 16 的特徵表相同、抓到與多列的個數要和 Day 19 相同，這同時也驗證了今天的評分沒有偷偷改規則

3. 核心技術深度拆解

3.1 兩種題目、三個模型：題目和答案都是現成的

簡單題是 Day 16 的看圖填欄位，一張廣告圖給 Gemini，請它填五個固定欄位，有沒有人物、行動呼籲按鈕的位置、主色、文字多寡和標題，前四個是選擇題，標題是照抄，24 張圖的四個選擇題共 96 格，其中 1 格在 Day 16 請另一個 AI 助手獨立判讀時就標成和規格不同，不計分，所以滿分 95，標題 24 格另外算。

難題是 Day 19 給文字的那一輪，廣告圖加上它導去的頁面文字，請 Gemini 列出廣告有寫、頁面找不到或說法不同的地方，事先寫好的計分落差有 21 個，這一題要讀圖上的字、讀頁面文字、兩邊對照之後再判斷算不算落差，比填欄位多了好幾步。

模型用系列一路用下來的三個等級：

單價是每百萬 Token 的美元價格，前兩個是非 global 端點的價格，Pro 是 global 端點的價格，原因在 3.4 說明，Pro 沒有做簡單題，因為最便宜的模型在 Day 16 就幾乎全對，再貴的模型也只能拿到一樣的分數，花這筆錢量不出東西。

兩種題目乘上模型一共五個組合，簡單題 × flash-lite 和難題 × 3.6-flash 前幾天已經問過，reuse.sql 把那 48 筆成功的呼叫紀錄抄進今天的紀錄表 mm_bench_log，今天實際新問的只有三個組合。

3.2 簡單題：最便宜的模型就拿滿分，貴的那個沒有多對任何一格

兩個模型都是滿分，兩邊和設計規格唯一不同的是同一格，cr-meta-trn-r2 的主色，規格寫冷色、兩個模型都答中性色，這一格就是 Day 16 的判讀者也和規格不同、所以不計分的那一格，那張圖的背景是淺灰牆和水泥地，兩個不同等級的模型給了同一個答案，比較像是規格那一格和畫面對不上。

費用是 2.2 倍，多買到的正確率是零，看圖填固定欄位這種工作，選項事先用 enum 鎖住、判斷標準寫進題目之後，剩下的就是把圖看清楚，這件事最便宜的模型已經做得到。

這個結論有前提，題目是 Day 15 用五輪實驗調出來的，當時只列選項、沒給判斷標準的那一輪就出過錯，今天量的是題目寫清楚之後的 flash-lite，不是隨便問一句的 flash-lite。

貴的模型反而多了一個狀況，3.6-flash 有 1 次回答被輸出上限 256 截斷，BigQuery 回報解析失敗，重問一次就成功，flash-lite 在 Day 16 的 24 次沒有發生過，所以這個組合的紀錄是 25 列，從費用回推多的那一次也有計費。

3.3 難題：18、20、21，差別不只是漏掉幾個

題目換成要對照兩邊再判斷之後，三個等級就分開了，成績剛好照價格排，但只看抓到幾個會低估差距，值得看的是每個模型錯在哪裡。

flash-lite 漏掉的 3 個分別是 cr-line-evg-p2 的「免運」、cr-meta-aut-p2 的「限定」和 cr-line-trn-r1 的「專案價」，三個都有同一個特徵，那幾個字它都有抄進廣告文字，只是沒有列成落差，圖上的字讀得到，漏的是對照頁面之後下判斷的那一步。

多列的 5 個更能說明問題，其中 3 個是把徽章「新品」填進別的種類，2 次填成限時限量、1 次填成商品選項，題目的清單裡沒有「新品」這一種，照規則應該填 other，它卻挑了一個看起來最接近的格子，另外 2 個是把不算落差的地方列出來，「一條包得住的大浴巾」對頁面的「純棉大浴巾」被列成商品名稱不符，還有一次把短襪列成商品選項。

同樣是「新品」，Pro 的處理方式完全不同，它列了 4 次，4 次都填在 other，分類沒有填錯，所以多列是 0，3.6-flash 漏掉的那一個就是 Day 19 已經看過的 cr-line-evg-p1，把「多色可選」抄成「多色選」少了一個字，照事先定好的規則算成漏掉一個、多列一個，flash-lite 和 Pro 這一格都抄對了。

換成實際使用時的樣子，不算有爭議和填 other 的，flash-lite 列出 23 項，其中 18 項是真的，每 5 項就有 1 項要人看過之後劃掉，而且還有 3 個真的落差沒有出現在清單上，3.6-flash 列出 21 項、20 項是真的，Pro 列出 21 項全部是真的，如果這份清單是要交給人逐項處理，便宜模型省下來的費用有一部分會變成看清單的時間。

三個模型有幾件事是一樣的，清單上故意放的兩種不存在的落差，贈品和保固，三個模型都沒有填過，6 張沒有任何計分落差的廣告圖也都沒有被多列，有爭議、不計分的 9 列三個模型各列了 4 個，最便宜的模型會分錯類、會漏判，但沒有在完全沒問題的圖上編出問題。

3.4 費用與時間：Pro 多抓 1 個，價格是 3.6-flash 的 2.9 倍

難題從 flash-lite 換到 3.6-flash，費用是 2.5 倍，多抓到 2 個、少多列 4 個，再從 3.6-flash 換到 Pro，費用是 2.9 倍，多抓到 1 個、少多列 1 個，越往上每一塊錢買到的改善越少。

三個模型在難題的輸入差不多，平均在 2,148 個 Token 上下，因為題目和圖是同一份，差別在單價和輸出，輸出含思考的平均是 flash-lite 116、3.6-flash 190、Pro 252 個 Token，貴的模型單價高、輸出加思考的 Token 也比較多，兩件事疊在一起，flash-lite 雖然接受 thinking_level LOW 這個設定，回來的思考 Token 欄位卻是空的，看起來沒有用到思考。

時間的差距比費用小一些，「一批等多久」量的是 BigQuery 把一批呼叫平行送出去、等全部回來的秒數，不是單次呼叫的延遲，flash-lite 一批 4 秒左右，Pro 一批 20.4 秒，大約 5 倍，批次處理的話 20 秒不是問題，要放在客人等著看結果的地方就要另外考慮。

Pro 還有一件和另外兩個不同的事，它是預覽版，在 BigQuery 的 us 位置叫不動，只寫模型名稱會被擋下來，要把 endpoint 寫成 global 端點的完整網址：

endpoint => 'https://aiplatform.googleapis.com/v1/projects/PROJECT_ID/locations/global/publishers/google/models/gemini-3.1-pro-preview',

所以 Pro 用的是 global 端點的單價，另外兩個模型只寫模型名稱、走的是非 global 端點，單價高一成，這張表不是完全站在同一條線上比的，另外兩個模型如果也改走 global，和 Pro 的差距還會再大一點。

這些數字要搭配幾個限制一起讀，每個組合每張圖只問了一次，21 個落差其實是五種落差在不同圖上重複出現，差 1 個可能只是運氣，18 和 21 的差距加上錯法明顯不同才比較有把握，沿用的兩組是前幾天問的、新的三組是今天問的，不是同一個時間點，每批的張數是 22 到 24 張也不完全相同，新問的組合正常是先試 1 張、其餘 23 張一批，我這次前兩個組合試了兩次所以是 22 張，時間只能看出差幾倍這種大差別。

4. FinOps 成本防護實踐：三道防線體系

1. 第一道防線：善用 Google Cloud 每月免費額度：沿用舊紀錄、對答案、檢查與報表都是查詢，在 BigQuery 每月 1 TiB 的查詢免費額度內，新增的呼叫紀錄表和兩張成績表只有幾百列，在每月 10 GiB 的免費儲存額度內
2. 第二道防線：架構層被動成本防護：五個組合裡兩個直接沿用前幾天的紀錄，一次呼叫都沒有多花，剩下三個組合 run.sh 先依「這次真的要呼叫的次數」印出兩個數字，照前幾天實測用量估的預期金額和輸出全部寫滿上限的金額，輸入 yes 之後每個組合先只試一張，看模型叫不叫得動、實際用掉多少 Token，再問一次才把其餘的跑完
3. 第三道防線：Cloud Billing 預算警報：沿用 Day 03 由 Terraform 建立的預算警報，50%、80%、100% 三段通知，今天的操作不會觸發

事前估的是預期 12 到 13 元、寫滿上限約 32.6 元（當時 Pro 還用非 global 的單價估，改成 global 之後 run.sh 印出來的是預期約 13.3 元、上限約 30.2 元），實付 7.61 元，另外有一次確認 Pro 叫得動的小呼叫約 0.03 元，73 次裡 Pro 只佔 24 次，費用卻佔了七成四，評測這種事最貴的永遠是最大的那個模型，先決定它只做哪些題目，比事後省任何東西都有效。

先試一張的設計今天真的派上用場，第一次執行時 Pro 在試跑那一步就被 BigQuery 擋下，那一段查詢失敗、沒有收費，前面兩個組合只各花了一張的錢，如果是一口氣送出去，前面兩個組合 48 次都已經花了錢，還要回頭查是哪一段出錯，費用依各模型的單價與實際 Token 數算出，匯率以 1 美元約 32 元計，實際以帳單為準。

5. Cloud Shell 實戰演練：一行指令換三個模型

5.1 事前準備

• 先在 ~/ai-driven-martech-pipeline 執行 git pull，取得 Day 20 的 benchmark/ 目錄
• gcloud config get-value project 要印出你的專案 ID
• 已完成 Day 16（bash features/run.sh）與 Day 19（bash consistency/run.sh），今天要沿用這兩天的呼叫紀錄和答案表
• 確認 gcloud 有登入中的帳號，輸入 gcloud auth list，帳號前面要有星號

5.2 路線 A｜懶人包：一行指令跑完

cd ~/ai-driven-martech-pipeline && git pull && bash benchmark/run.sh

run.sh 先確認前幾天的表都在、題目沒有未 commit 的修改，做三項不花錢的檢查，把前幾天的紀錄抄進來，印出這次要呼叫幾次和估價，輸入 yes 之後每個組合試一張，再輸入一次 yes 才跑完其餘的，接著馬上重跑一次確認不重複收費，有呼叫沒成功時這一步會再問一次、只補沒成功的，最後是對答案、20 項檢查、十段報表和一段時間報表，每一次要花錢之前都會停下來問，沒有跳過確認的選項。

5.3 路線 B｜逐步教學：理解每一個步驟

步驟 1：沿用前幾天的紀錄

cd ~/ai-driven-martech-pipeline
PROJECT_ID=$(gcloud config get-value project)
bq query --nouse_legacy_sql --format=pretty < benchmark/reuse.sql

reuse.sql 建立呼叫紀錄表 mm_bench_log，把 Day 16 與 Day 19 成功的 48 筆紀錄抄進來，這一步不呼叫 Gemini。

步驟 2：補問剩下的組合

sed "s/PROJECT_ID/${PROJECT_ID}/g" benchmark/bench.sql \
  | bq query --nouse_legacy_sql --format=pretty --parameter=batch_limit:INT64:24

這一步會呼叫 Gemini，三個組合約新台幣 7.6 元，直接執行不會先問，batch_limit 是每個組合這次最多問幾張，想先試一張就改成 1，成功過的組合不會再問。

步驟 3：對答案、檢查與報表

bq query --nouse_legacy_sql --format=pretty < benchmark/score.sql
bq query --nouse_legacy_sql --format=pretty < benchmark/check.sql
bq query --nouse_legacy_sql --format=pretty --max_rows=300 < benchmark/report.sql
bq query --nouse_legacy_sql --format=pretty < benchmark/timing.sql

score.sql 用 Day 16 和 Day 19 原本的規則對答案，放進 mart_bench_features 與 mart_bench_gaps，check.sql 是 17 項流程檢查，另外三項由 run.sh 補上，report.sql 十段分別是紀錄來源、兩種題目的總成績與分項、答錯和漏掉的原文、有爭議與 other 的列、費用，最後一段是一張表看完的總表，timing.sql 讀專案的工作紀錄算一批跑了幾秒，沒有權限看工作紀錄時 run.sh 會跳過這一段。

5.4 驗證成果

• mm_bench_log 五個組合都有 24 筆成功的紀錄，沿用的兩組來源顯示 day16、day19，新問的三組顯示 day20
• 報表第 2 段的 no_call 是 0、第 5 段三個模型的 answers 都是 21，不是的話代表有組合沒做完，成績不能直接拿來比
• run.sh 的 20 項檢查全部通過，緊接著的重跑只補還沒成功的，全部成功時是 0 次

Gemini 每次的回答不會完全一樣，你跑出來的格數可能和這裡差一兩格。

5.5 用完後怎麼處理

mm_bench_log 和兩張成績表都留著，之後有新模型推出，在 bench.sql 的組合清單和呼叫各加一段，run.sh 的檢查與單價表也跟著加一個模型，就可以用同一份題目和答案再比一次，前面問過的組合不會重問。

6. 工程實務避坑指南

1. 預覽版模型不一定在你的位置叫得動：gemini-3.1-pro-preview 在 us 位置沒有，只寫模型名稱會回 Unsupported endpoint，要改寫成 global 端點的完整網址，單價也跟著換一套，先用一張圖試過再整批送
2. 比模型的時候只能動一個地方：題目順手改一句、輸出上限順手調大，量到的就不是模型的差別，今天是用程式把每一段呼叫和原文逐字比對，除了 endpoint 之外有任何不同就不呼叫
3. 輸出上限對每個模型的鬆緊不一樣：同樣是 256，flash-lite 24 次都夠用，3.6-flash 就有 1 次被截斷，難題把上限設在 2,048，Pro 最多的一次用到 1,426 個 Token（含思考），換模型之後要回頭看有沒有回答被截掉
4. 只看抓到幾個會漏掉一半的事：flash-lite 的 18／21 看起來不差，但它另外多列了 5 個，成績要連同多列的數量和原文一起看
5. 每格只問一次的成績不要比到小數點：20 和 21 的差距可能換一天問就反過來，要下結論至少要差距夠大、而且錯的方式看得出不同

7. 總結與明日預告

今天把 Day 16 的看圖填欄位和 Day 19 的廣告對頁面，原封不動交給三個等級的 Gemini，簡單題最便宜的 gemini-3.5-flash-lite 和 gemini-3.6-flash 都是 95／95，難題的 21 個落差分別抓到 18、20、21 個，問 1,000 張的費用是新台幣 32.9、81.8 和 234.5 元，今天新問的 73 次合計約新台幣 7.6 元。

回到篇名，便宜的輕量模型夠不夠用要看交給它的是哪一種工作，看圖填固定欄位這種題目它拿滿分，貴的模型花 2.2 倍的錢沒有多對任何一格，要對照兩邊再判斷的題目它就會漏、會分錯類，這時候換成 3.6-flash 是划算的，再往上到 Pro 多抓到的只剩 1 個，價格卻是 2.9 倍，前面十幾天憑直覺做的選擇，簡單的用 flash-lite、難的用 3.6-flash，今天有數字可以支持了。

明日預告：Day 21《教 AI 自己去查資料庫免得它在那邊瞎猜》，到今天為止都是我們把資料整理好再交給 Gemini，明天反過來，把查詢資料的工具定義好交給它，讓它自己決定什麼時候該查、要查什麼。